Skip to content

Fix multiarch compatibility #206

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Fix multiarch compatibility #206

wants to merge 2 commits into from

Conversation

@ghisvail
Copy link
Contributor

@ghisvail ghisvail commented Aug 24, 2016

At the moment, glbinding is not compatible with multiarch systems. This PR modifies the installation path variables and target settings to achieve this.

The first commit uses GNUInstallDirs to provide the multiarch install paths. This is a pretty standard solution and keeps the old behavior in case the system is not multiarch.

The second commit addresses CMake detection on multiarch (and non-multiarch) systems. The old settings were not flexible enough and not exactly compliant with what CMake recommends in their tutotrials. Considering the simplicity of your project (one library), the simplest solution is to put the CMake package config file alongside the target file and just include it.

Let me know whether you have any questions.

@ghisvail
Use GNUInstallDirs.
896a780 
Gbp-Pq: Name Use-GNUInstallDirs.patch
@ghisvail
Fix CMake packaging.
e2a7668 
Gbp-Pq: Name Fix-CMake-packaging-setup.patch
@scheibel
Copy link
Member

scheibel commented Aug 29, 2016

Thanks for this PR.
Most of it looks promising but I'm not sure how the adapted cmake configure script handles multiple architectures and build-types (the first is your, the latter our requirement).

I will discuss this with the other maintainers.

@scheibel scheibel mentioned this pull request Aug 29, 2016
Open
4 tasks
@scheibel
Copy link
Member

scheibel commented Aug 29, 2016

It may be that the differing build-types are actually another issue (cginternals/cmake-init#36).

@ghisvail
Copy link
Contributor Author

ghisvail commented Aug 30, 2016

It may be that the differing build-types are actually another issue (cginternals/cmake-init#36).

Indeed.

how the adapted cmake configure script handles multiple architectures

/usr/lib/cmake/<arch>/<project> is part of the default paths searched by CMake for config files, so is /usr/lib/cmake/<project> or usr/share/cmake/<project>. In Debian, the latter 2 are used for arch-independent libraries such as those which are headers-only.

...and build-types

CMake should create both a <target> and a <target>-<build_type> file in the CMake config path. You can have as many <target>-<build_type> as your number of supported build types (for instance Debug and Release). Then, find_package will do its magic and you can use generator expressions on the imported target to dispatch what is specific to Debug and Release respectively.

@n3rdopolis
Copy link

n3rdopolis commented Apr 5, 2023

This commit seems to work pretty good, is there a reason why it was never merged?

@n3rdopolis
Copy link

n3rdopolis commented Sep 8, 2023

@scheibel The changes in this PR still seems to work BTW.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

Deployment needs review

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@ghisvail @scheibel @n3rdopolis @sbusch42